Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

Thanks, this makes sense.
Is there any reason not to do this for all eval_nullary_intrinsic?

Cc @oli-obk

Is there any reason not to do this for all eval_nullary_intrinsic?

I could be useful for optimizations to evaluate variant_count::<Option<T>>() or needs_drop::<ManuallyDrop<T>>() as soon as possible.

I do have a test case, but wasn't sure if we want one that depends on const_evaluatable_unchecked; following compiles on nightly:

#![feature(const_generics)]

struct Value<const B: bool> {}
impl Value<true> { fn is_true() {} }

fn f<T>() {
    Value::<{std::mem::needs_drop::<T>()}>::is_true();
}
fn main() {
    f::<u32>();
}

I could be useful for optimizations to evaluate variant_count::<Option>() or needs_drop::<ManuallyDrop>() as soon as possible.

Well, for the latter that won't happen any more with this PR, right?
If we want this, we need a needs_drop inside rustc that can answer "yes", "no", and "don't know".

Well, for the latter that won't happen any more with this PR, right?

For variant_count we already have suitable implementation, for needs_drop we would need to change it.

Ah, fair.

Then maybe add comments to the other branches (the ones that do not call "ensure_monomorphic") explicitly saying "this code will correctly handle non-monomorphic calls" or so. I want to make sure that when/if another intrinsic is added, we don't introduce the same bug again...

r? @RalfJung

Code change looks good to me; is there any way to have a test for this? r=me otherwise.

Added a test case mentioned earlier.

Awesome, thanks a lot. :)
@bors r+

📌 Commit 07a03b0 has been approved by RalfJung

⌛ Testing commit 07a03b0 with merge 66ba810...

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 66ba810 to master...